%\todo{that below is todo:}
%\begin{itemize}
%\item list different knowledge sources google maps, ICS calendar streams, public transport advice sources, 
%weather forecast sites,
%the users phone, social media?. 
%\item explain how we will use and combine these sources
%\item explain for what we will use them
%\end{itemize}
%
%(this section) Could be moved to before system architecture?


There are different sources of knowledge. These include ICS formatted calendar streams, public transport
advice sources, weather forecast sources but also user phone information and learned information. 
Some of these are more reliable than others and not every source is always necessary as some 
can only be used to increase performance or enhance the user friendliness. 

\paragraph{ICS File Format} The ICS File format is supported by a large number of calendar products. 
The first products that come to mind are Google Calendar, Apple iCal and Microsoft Outlook. There are
standard libraries that deal with the processing of these streams. With the ICS file format as basis
we can use information stored by the other products the user uses per default. This type of information
can be used to find open matching spots in multiple people's agenda's.  

This source is very reliable as we either build up a ``database'' ourselves or start with a ``database'' 
imported from the calendar application the user used before us. 

\paragraph{Geographical Information} Geographical information can be used to plan a journey to 
one place or another. The planning process should take the user preferences in to consideration. 
These can exist of travelling by bike, car, foot or travelling by public transport. For the first
three options geographical information is necessary. Google Maps has an API that will allow 
for this kind travelling advice to be made. 

This source is very reliable.

\paragraph{Public Transport Advice} There are several problems here. First of all, the source for information
about public transport schedules are not the same everywhere. In the Netherlands everyone is limited to 
the sites of the different public transport companies (think of the Nationale Spoorwegen \cite{ns}) or one site 
that includes more public transport companies (think of 9292 \cite{9292}). If we were to use sites such 
as these the only solution would be to parse these sites. Changes in the sites will be problematic for 
the continuity of our application. 

In other countries some public transport schedules might be openly available for anyone directly through 
an API. This is done to support the open source community. In the Netherlands the openov project \cite{openov}
is working on this but the API is not yet open. 
Changes in APIs are mostly backward compatible so 
that would mean less work for maintenance. These sources are few in numbers so it might still not be 
a better alternative and, either way, sources differ on where the application is used.

The last solution is to parse Google Maps for travel advice. For some cities Google Maps has the ability 
to also plan the public transport. This option is not yet supported everywhere but we can hopefully trust
Google that they will continue to work on making this option available to everyone. The Google Maps API
does not yet support this function. This means we should parse the Google Maps site. This is a shame but
this is still the best option. 

This source is very unreliable as public transport advice might not be supported at your location or 
Google might have pushed some changes that require us to review the parsing process.

\paragraph{Weather Forecast} Rain can make a dandy bike trip horrible. Buienradar \cite{buienradar} 
has an API that is perfect to use. There are rumors that the API would not remain free but even so 
it is still the best option. The scale of the radar coverage is increased to Europe and even the rest
of the world seems promising. 

This source is reliable.

\paragraph{Phone Information} Some information that we can use is stored in the phone of the user. 
This concerns the following information: contact information, phone location and phone status. 
Applications (apps) that can be installed on current smartphones ask for permission to use this
information. The reliability for this information thus depends on the status of the phone: power 
status (is it turned on?) and connection status (is the phone well connected to the internet, mobile
network?). 

The reliability of this source is rather high because it is directly connected to the user by our
application. Some times it might fail due to causes that we can not control. We assume this will 
never continue for long enough to become a problem.

\paragraph{Learned Information} Which parameters do we learn? Obviously this kind of information
(and its reliability) increases over time. We should set default values for the settings that 
we learn that the user can adjust if it wants to. Whenever a user overwrites a default value or 
a machine learned value for a variable (that is a parameter) the machine will cease learning 
for this variable.

Any type of suggestion that is given by the PA and needs confirmation by the
user can be learned with a classifier. Examples are whether an event may be
moved or removed, or if an appointment may be made on a certain date and time
can be learned by all the other parameters. The values learned can be used to
predict how likely it is that a user will approve, and thus give better
suggestions over time.

If fields need to be auto-filled this can be also done with statistical
classifiers using the fields that we do know.

Travelling times can be learned with regression using distance, start and end
location, traffic reports, day of the week, time of the day, etc.

The reliability for this source is high. Even though it is absent in the beginning we can rely
on default values and on the user to correct wrong values.